Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 081 / newopus.arc / NEWOPUS.DOC next >

Wrap

Text File | 1987-10-13 | 39.0 KB | 892 lines

l---L----T----T----T----T----T----T----T----T----T----T----T----T----R----T----T T T T T T T r ------------------------------------------------------------------ NEWOPUS.DOC by Alan Applegate, The Short Line, 1:104/36 Lee Lasson, On-Line Consulting, 1:104/45 A document for assisting new Sysops in setting-up and operating an Opus-CBCS. Version: 1.00 Draft Last update: 10/10/87 Current to Opus Version: 1.03a Copyright (C) 1987 Alan D. Applegate and Lee Lasson, All Rights Reserved. Authorized for use by and distribution to all Opus Sysops, current and future. ------------------------------------------------------------------ INTRODUCTION Welcome to the wonderful world of Opus and FidoNet! We're confident that you'll enjoy being part of the worldwide FidoNet amateur electronic mail network. Currently, there are well over 2,000 electronic bulletin board systems that run FidoNet compatible software and are part of FidoNet. Boards are running in the United States, Canada, Great Britain, Germany, Indonesia, Japan, Australia and several other countries. Recently, FidoNet BBS's have been established behind the "iron curtain" in Poland! The fundemental requirement for being a part of FidoNet is the ability to send and receive mail during "National Mail Hour." This is the designated time for transferring mail between systems nationally. Once you have the ability to do this, you can apply for a node number. This document is designed to assist you in that process with an Opus-CBCS. You'll soon discover that operating Opus has much more to offer than simply being a BBS that can send and receive mail for one hour each day. Opus is an advanced mail handling system, designed to streamline mailing operations, including the sending and receiving of EchoMail conferences. It also offers a tremendous amount of flexibility for the Sysop in tailoring a system for his or her particular needs, and the needs of his or her users. With the extreme flexibility of Opus, comes a certain amount of complication and sophistication with the set-up of an operational system. This text, and the files included with it, are designed to take you from nothing, to an operational "bare-bones" Opus system. Many things are included here, but you'll find some files that will need to be obtained elsewhere. Please refer to the list later in this document for more information. Please remember to TAKE YOUR TIME. We know you're excited, and want to get going right away...but patience and care for details will take you a long way toward building a good, solid system. Remember also that this document is NOT intended to remove the necessity for the Opus documentation. You should print-out and keep handy the documentation for reference. Read through it at your leisure. We'll help you get started, then leave you to your own system. Enjoy being an Opus Sysop! Alan Applegate Lee Lasson GETTING STARTED A SPECIAL NOTE to Sysops who are upgrading from previous versions or other systems: The batch file included with this package creates and uses directories from the root titled \OPUS, \MSG and \FILE. If these directories already exist on your system, use the enclosed utility called RN.COM to rename the directories. This popular PC Magazine utility is a directory utility that may be of use to you outside of the realm of Opus. Failure to rename these directories if they already exist could cause problems if you use the batch file. Although we originally set-out to make a tutorial-type document for setting-up an Opus from scratch, we kind of got off-course. Instead, we made a complete package for setting-up an Opus. The following files contain almost everything you need to get started: NEWOPUS1.ARC Set #1 of Opus files NEWOPUS2.ARC Set #2 of Opus files NEWOPUS3.ARC Set #3 of Opus files Although this document may be of assistance to those who choose not to use these packages, the files are conveniently located in one place if you do. The files needed to build an Opus system normally come in about two or three dozen different pieces. Using these packages will also allow you to use the OINSTALL.BAT batch file that came with this document, which will install a working Opus system for you in minutes. In any case, you will need the latest versions of the following files. The names shown below represent the latest version (to our knowledge) as of the date of creation of this file: OPUS_103.ARC The latest version of Opus proper O_SYSDOC.ARC The latest version of Opus documentation ONODE146.ARC The latest Opus nodelist compiler OMMM_104.ARC The latest version of the Opus Matrix Masher XLATRGEN.ARC The latest version nodelist generator Xlatlist is used by all nodes in the net to generate a nodelist that the Opus nodelist compiler will in turn use to make a machine readable, final nodelist. Opus uses what is called a FOSSIL (Fido/Opus/SEAdog Standard Interface Layer) driver for accessing the communication port(s). It works as an interface between Opus and the hardware interrupt 14 (hex). Using such a driver allows Opus to run on hardware that implements the interrupt differently from the IBM PC. Here is a listing of FOSSIL drivers we know of: HZCOMM30.ARC For Heath/Zenith OCOM_29G.ARC For IBM PC and close compatibles ODEC_12.ARC For DEC Rainbow X00V1_06.ARC For IBM PC with multi-tasking in use OT2K_310.ARC For Tandy 2000 OPUS_TAN.ARC Patch for Tandy 1000's keyboard For an IBM or close compatible, OPUSCOMM (OCOM_29G.ARC) is recommended. X00 (X00V1_06.ARC) is also excellent, particularly in situations where multi-tasking is in use (DoubleDOS, etc.). Of course, there are literally dozens (perhaps hundreds!) of helpful utilities and programs that make being an Opus Sysop easier. For now, concentrate on getting the system operational. Add the extra bells and whistles LATER, and this includes trying to implement any of these extra utilities. NOTE: This document makes the assumption that you will be carrying at least one EchoMail area. In this case, the area is called FIDOSYSP. This area is the local Fido Sysops' Echo for the Denver area. If you are located in a different area, then you will need to make the appropriate changes once the system has been set-up. Although it is possible to set-up an Opus without EchoMail, it is strongly advised that you at least carry your net Sysops' Echo. The batch file included, and the rest of this kit, is geared to making that one area for you. PREPARING YOUR SYSTEM Before you start, keep in mind that Opus may require as much as 1.5 Megabytes of your hard disk right off the bat. Obviously, the more messages and files you make available on-line, the more disk space that will be required. Make preparations now...clear space if necessary. If you are unable or unwilling to make such a commitment of space, please do not proceed. The next section (Opus Cookbook) deals with assembling the system using the OINSTALL.BAT file included with NEWOPUS.ARC. If you are going to manually install Opus, skip to the sections after the cookbook. They describe the Opus files individually, and in more detail. OPUS "COOKBOOK" (Step-by-Step Instructions) This cookbook is intended to be used with the batch file called OINSTALL.BAT. The batch file was written to set-up a working Opus system automatically with a minimum of effort. You will need to do some things, however. PLEASE NOTE! The OINSTALL batch file and the whole NEWOPUS package makes the assumption that you will be using the C: hard drive for installation. If this is not the case, then manual installation is virtually a requirement. In addition, there are a multitude of files that will need to be changed, all of which reference the C: drive. It is beyond the scope of this document to attempt to take into consideration all possible installation combinations, such as installing on a drive other than C: drive. If you have more than one hard drive, it would be advised for simplicity's sake that you make changes to your system to re- arrange your files, rather than attempt to make manual changes to the several files in this package. Once the system is set-up, it's hardly a glamorous full-featured system. There's a lot to do still once you have it established. We've just taken the pain out of it, so that you can get to the fun. PLEASE REMEMBER! It is still important for you to have an understanding of what's going on. READ the Opus documentation. READ the information on files included below. LOOK at your system, and get in there and LEARN it! 1) Place the following files in your ROOT directory, C: drive: NEWOPUS1.ARC NEWOPUS2.ARC NEWOPUS3.ARC PKXARC.COM (Not included with this package) OINSTALL.BAT OPUS_103.ARC (Not included with this package) OMMM_104.ARC (Not included with this package) ONODE146.ARC (Not included with this package) XLATRGEN.ARC (Not included with this package) NOTE! It is advised that you have back-up copies of these files on floppy disk, should something go wrong during the installation process. To minimize disk space problems, the hard disk copies of these files are deleted after use! 2) Make sure that you have an AUTOEXEC.BAT file in the root directory. Most people have one of some sort. NOTE: The batch file WILL append some information to the AUTOEXEC.BAT file. 3) Making sure you're at the root directory, and making sure you have backup copies of the required files outlined above, run the OINSTALL.BAT batch file. Read the screen output, and pay attention to it. 4) As outlined previously, you need to obtain a FOSSIL driver for your system. For IBM users, X00 or OPUSNODE are required. Install the FOSSIL driver in accordance to the directions included with the FOSSIL. X00.SYS is installed via your CONFIG.SYS as a device driver. OPUSCOMM is loaded like a program, and is added to your AUTOEXEC.BAT file. 5) Change directory to \OPUS\NODELIST. Run XLATLIST (type XLATLIST at the DOS prompt, press ENTER). This file takes a distribution nodelist, and distribution nodelist difference files (if any) and creates a text file called NODELIST.BBS. You will do this on a weekly basis. We have included a sample distribution nodelist in the package. Read the XLATLIST.DOC file for further information. 6) Compile the NODELIST.BBS into a form Opus can use. Use the nodelist compiler, called OPUSNODE, to do this. At the prompt, type: opusnode -f Two files will result. NODELIST.SYS and NODELIST.IDX. These are the nodelists that Opus uses directly. 7) Change to the \OPUS directory. Create a USER.BBS file by running the program called MK_USER. The syntax is MK_USER <firstname> <lastname> <password>. That should be YOUR names and password. This creates the USER.BBS, and makes the first entry in it. You can deleted MK_USER after use. 8) Change the BBS.CTL file with a text editor of some sort. Find your modem, and uncomment the line. Uncomment means to remove the % sign from the front of the line that says "Modem Init String." Uncomment your modem port...COM1 is already uncommented, erase it and uncomment COM2 if you use COM2 instead. Change the line "Sysop New Sysop" to "Sysop" followed by your name. Change the line "System" to the name of your system. DO NOT CHANGE the node address, currently listed as 104/99, until you are officially assigned a node number. 9) Compile BBS.CTL. At the DOS prompt, type OPUS_CTL BBS and press ENTER. You will use this procedure EACH time you make a change to the BBS.CTL file. 10) Edit the OMMM.CTL and ECHO.CTL to reflect who is sending you EchoMail. If you are not sure yet (often this is assigned when you are assigned a node number) you may use 104/36. 11) Start your system. If you used X00 as a FOSSIL, you will need to re-boot. Opus will start automatically, as reflected in your modified batch file. If you used OPUSCOMM as a FOSSIL, make sure it has been added to your AUTOEXEC.BAT manually, then re-boot your system. Opus will start automatically. 12) Now, log-in and send a message to either 104/36 or 104/45. At the keyboard, type a single letter K at the keyboard (do not press ENTER), then log-on as you normally would as a user. Address the message to "Sysop" of the board you send it to. 13) Send a message to 104/0, Oscar Barlow, and request your node number. You will need to include: Your Name City Voice Telephone Number Software and System In Use BBS Name Maximum Supported Baud Rate Hours of Operation (Must Include National Mail Hour) Is Registration Required BBS Telephone Number 14) After you get the node number, you will need to: Run MAILSYS.EXE (included, and located in C:\OPUS) Edit BBS.CTL (to reflect your node number assignment) Edit XLATLIST.CTL (in C:\OPUS\NODELIST) to reflect your node number assignment. 15) You're on your own! The .BBS files located in C:\OPUS\MISC will need to be customized by you if desired. They are plain, and totally generic. In fact, your users will be confused if they see half the stuff that will be displayed until you change these files. Look around...and sniff out things to change. You'll get ideas and information from the Opus documentation. Have fun! It's a hobby for most of us...if you get frustrated, leave it for a while. If you have questions or problems, contact one of the Opus Help Nodes for Denver: Alan Applegate The Short Line 1:104/36 Steve Carnes This End Up 1:104/30 THE FILES IN C:\OPUS ARCA.COM This is an archive creation utility. It often comes under a different, although similar name. You MUST have this file named as shown, and available to Opus in the main Opus directory. Regular ARC or PKARC are NOT acceptable substitutes for this file. ARCE.COM This is an archive extraction utility. The notes under ARCA.COM apply. Regular ARC or PKXARC are NOT acceptable substitutes for this file. BBS.CTL This is the main Opus control file. Much of Opus' operation is defined here, including time limits, your system name and node address, external files in use, and so on. Commonly available is a sample file called OPUS.CTL. This file, written by Wynn Wagner, is a sample control file with complete notations on all definable functions available to you. This file can be manipulated by any text editor or word processor that can handle ASCII text files. After editing, this file is compiled (it's the only control file that cannot be used by Opus in text form). The program OPUS_CTL does the compiling. It's described later. Included with this package is a sample file as well that has some of the common functions already put together for you. The OPUS.CTL sample file has excellent explanations of the various functions. We'll point out a few special points in our sample file. Load our BBS.CTL into your text editor, and follow along: % % This is set-up for a 1200 baud Hayes modem as COM1: % Baud 1200 Modem Init |AT Q0 E0 S0=1 S7=45 S9=2 S10=20 H0 M0 X4 V1| Modem Dial Prefix ATDT Modem Dial Suffix | Modem COM1 Modem Busy ~AT H1 M0| Mask Carrier 128 % % Your system info here. % Sysop Alan Applegate System The Short Line *toot-toot* - (303)-969-9510 Log c:\opus\opus.log Snoop Verbose Video IBM % % If you're setting-up in Net 104 (Denver area) you are in % zone 1, and assign yourself an address of 104/99 to apply % for a node number Zone 1 Matrix Address 104/99 Matrix Send Local Matrix Messages c:\msg\net\ Matrix Files c:\file\net\ Matrix Hold_Area c:\opus\outbound\ Path Netinfo c:\opus\ Matrix After Edit Exit 7 % % These are the EchoMail statements (some other ones are % elsewhere...we are assuming that you run EchoMail % Echo Exit 7 Matrix Scan EchoMail Matrix Kludge Hidden Matrix Extract ArcMail Matrix Toss EchoMail Matrix Ask Crash Sysop Matrix Ask FileAttach Sysop Matrix Ask KillSent Extra % % The following three files are cutomized by you. They % refer to the file request capabilities of Opus. Please % refer to the Opus documentation for information on these % files. They are named something obscure for now. When % you compile this control file with OPUS_CTL, you *must* % have these files created, or the compiler may bomb out. % Come back to them later if you want. % Matrix About c:\opus\system.txt Matrix Okfile c:\opus\okfile.txt Matrix Avail c:\opus\files.txt Outside Exit 5 Echo Seenby Hidden Graphics 1200 Define Twit Time 2 Define Disgrace Time 10 Define Normal Time 20 Define Privel Time 45 Define Extra Time 60 Define Asstsysop Time 120 Define Sysop Time 240 Define Twit Cume 2 Define Disgrace Cume 15 Define Normal Cume 40 Define Privel Cume 90 Define Extra Cume 120 Define Asstsysop Cume 240 Define Sysop Cume 480 Define Normal File Limit 200 Define Privel File Limit 300 Define Extra File Limit 400 Define Sysop File Limit 1000 Path System c:\opus\ Path FPath c:\opus\misc\ Reboot on Carrier Loss % % Most of the following files must be physically present on % the system when you compile this file, or it may bomb out. % All of these files should be included in the ones that go % in your C:\OPUS\MSC directory. % Uses Locate c:\opus\misc\locate Uses Contents c:\opus\misc\contents Uses XferBaud c:\opus\misc\xferbaud Uses Filearea c:\opus\misc\filearea Uses Timewarn c:\opus\misc\timewarn Uses Msgarea c:\opus\misc\msgarea Uses Inquire c:\opus\misc\inquire Uses Edit c:\opus\misc\editor Uses Replace c:\opus\misc\rep_edit Uses Application c:\opus\misc\qnewuser Uses OPed c:\opus\misc\oped Uses Questionnaire c:\opus\misc\question Uses Edtorial c:\opus\misc\edtorial Uses Byebye c:\opus\misc\byebye Uses Tooslow c:\opus\misc\tooslow Uses Daylimit c:\opus\misc\daylimit Uses Newuser1 c:\opus\misc\newuser1 Uses Newuser2 c:\opus\misc\newuser2 Uses Bulletin c:\opus\misc\bulletin Uses Rookie c:\opus\misc\rookie Uses Welcome c:\opus\misc\welcome Uses Logo c:\opus\misc\logo Uses Password c:\opus\user Uses Schedule c:\opus\sched Kill Ask Format Date %D-%C-%Y Format Time %E:%M%A ECHO.CTL This is the EchoMail control file. For those familiar with EchoMail operation with non-Opus systems, this file roughly corresponds to the AREAS.BBS file. For each EchoMail area you carry, this file has one listing that contains the numeric message area designator (message area number), fully qualified drive and path (the directory where your messages for this area are kept), "EchoTag," and a list of the nodes you get the Echo from and/or send it to. Here now is a copy of the sample file that is included with this system. Remember that this tutorial package assumes that you will carry at least one EchoMail area. It is very much advised that you at least carry the local Sysops' EchoMail Conference. 2 c:\msg\reviews REVIEWS 104/17 104/31 104/30 104/40 3 c:\msg\usawide USAWIDE 104/40 4 c:\msg\denver DENVER 104/31 5 c:\msg\newopus NEWOPUS 104/56 6 c:\msg\netdev NET_DEV 104/904 7 c:\msg\region15 REGION15 104/904 8 c:\msg\fidosysp FIDOSYSP 104/904 10 c:\msg\corp LBSI 104/40 Notice that there is no trailing backslash (\) on the path. The EchoTag is the word that Opus uses to determine which EchoMail messages belong where on your system. This word is contained inside each EchoMail message on a line just before the message text. The line is called an AREA line, since it designates the message area. Although the EchoTag can be upwards of 60 characters long, in practice it is USUALLY never longer than 8 characters, and is always in upper case. If this EchoTag does not match the one in the AREA line in the message EXACTLY, in-coming messages will NOT be tossed correctly. Check with the individual who sends you the EchoMail area as to what the exact EchoTag is. The node or nodes on the end of this list tells Opus who to forward messages to. In most cases, this will only be one node address, the address of the board that sends you the area. In the above example, the first entry (the area called REVIEWS) is sent to several nodes. Whenever a message is received for this area, it is packed-up and sent to each node in the list that has not yet received the message. It is important to insert a carriage return sequence after the last entry in this control file. When using a text editor to edit the file, simply press ENTER once or twice at the end of the file to make sure this requirement is met. TGET.EXE This file allows you to make Opus "WaZoo" file requests from other Opus systems. This file is similar to many other files with similar names like OGET. The primary difference is that TGET also builds an out-going message so that Opus will actually send your file request without further action. We do not advise trying to play with this right-off...it is included here for your convenience. OMMM.CTL This file is the control file for the Opus Matrix Masher. The matrix masher is essentially what controls routing of EchoMail with Opus. For all practical purposes, you do not need to include any nodes in this list that you do not trade EchoMail with. Here is the sample contained in this package: crash 104/904 104/904 crash 104/56 104/56 114/15 104/37 104/34 arcto 104/17 104/17 crash 104/40 104/40 arcto 104/30 104/30 hold 104/31 104/31 The format of each line in this file is: <verb> <destination> <route_list> The <verb> is simply a "flavor" or type of routing. The <destination> is the node to whom the mail packet will sent. The <route_list> is the listing of nodes whose mail will be routed to the <destination> with the "flavor" shown as the <verb>. Line two above shows that the verb is "crash." This means that depending on what the current Z/Matrix event (discussed later) is, mail for 104/56, 114/15, 104/37 and 104/34 will be sent to 104/56 immediately, or as soon as possible. The "crash" verb should only be used for mail to a system that supports continuous mail (Opus systems, systems running SEAdog). Note that 104/56 in line two is listed TWICE. The first appearance is as the <destination>...the mail will sent to 104/56. It's listed again since you want mail for 104/56 to be sent to 104/56...that node number is also part of the <route_list>. Line three above shows the "arcto" verb. This means that the message(s) will be packed-up and readied for sending, but that sending will wait until an event (Z/Matrix event) where accepting continuous (crash) mail is NOT a requirement of the receiving system. Z/Matrix events are explained later. You would use this verb for sending EchoMail to systems that do not operate 24 hours (regardless of software), or that do not accept continuous mail (Fido Version 11W for example). The last line above shows the "hold" verb. This means to pack the mail up, but let it sit for pick-up by the destination system. This is done where another Sysop would prefer not to be automatically called, but instead, "poll" you for his or her mail. Other verbs are available, please refer to the Opus documentation. You should have no need for the other verbs, however, unless you have a very unusual or special situation. Again, you shouldn't need to list any nodes or do any routing of mail unless you trade EchoMail with a particular node. In that case, you would simply list your EchoMail host node address twice after a "crash" verb, as most EchoMail hosts operate continuous mail. You MUST have an OMMM.CTL file present however, and you should at least have one listing...the listing for the node that you obtain your one or more EchoMail area(s) from. RUNOPUS.BAT This is a simple batch file used to run Opus. Why run Opus in a batch file? Opus, like other BBS systems, uses the batch file to handle DOS "errorlevel" environment variables. In order to perform certain functions, Opus ends, setting the DOS variable ERRORLEVEL to a certain value. The batch file, in turn, determines the ERRORLEVEL value, and acts accordingly. This method is always used with Opus to run OMMM (the matrix masher), and may optionally be used to run external programs such as RENUM (a message area maintenance program). The sample batch file shown here performs a variety of functions. Each will be described: echo off cls rem --- The following word (start) is a batch file label...this is rem --- much like subroutines in a program. The batch file can rem --- "goto" these labels much like BASIC programming. rem --- The first label is called "start"... :start OPUS BBS -NL -NF rem --- The "BBS" shown in the command line is the name of your rem --- .PRM file, explained below in the OPUS_CTL section... rem --- The command line switches are used above are temporary rem --- fix jobs for Opus prepared by the author. Refer to some rem --- text files included with OPUS_103.EXE for an explanation. rem rem --- The following are the ERRORLEVEL branches for this sample rem --- Opus. rem rem --- 255 is a capture for the C compiler used to compile Opus if ERRORLEVEL 255 goto start rem --- 30 is set via an external event programmed by the rem --- Sysop. In this case, it is used to automatically process rem --- the nodelist weekly if ERRORLEVEL 30 goto xlatlist rem --- 20 is set via an external event programmed by the rem --- Sysop. In this case, it is used to run RENUM if ERRORLEVEL 20 goto renum rem --- 8 is just a special one to cause recycling if ERRORLEVEL 8 goto start rem --- 7 is set in the BBS.CTL to be the exit ERRORLEVEL used rem --- when the system needs to run OMMM (the matrix masher) if ERRORLEVEL 7 goto bundles rem --- 5 is set in the BBS.CTL to be the exit ERRORLEVEL used rem --- in conjunction with the O)utside command on the main menu if ERRORLEVEL 5 goto outside rem --- 3 is a serious system error, stop operation if ERRORLEVEL 3 goto end rem --- 2 is a minor error, recycle if ERRORLEVEL 2 goto start rem --- 1 is generated when you press control-C at the local rem --- console if ERRORLEVEL 1 goto end rem --- 0 miscellanous error, recycle if ERRORLEVEL 0 goto start rem --- These are the operations used for automatic nodelist rem --- processing, re: ERRORLEVEL 30. They are included here rem --- only as a demonstration. You might want to delete this rem --- complete group of operations (to the :renum label) and rem --- make a change to your event schedule. Since all the rem --- lines are commented out, leaving will not hurt anything. :xlatlist rem if not exist c:\file\net\nodediff.a* goto start rem cd \opus\nodelist rem copy c:\file\net\nodediff.a* rem del c:\file\net\nodediff.a* rem a:pkxarc nodediff.a* rem del nodediff.a* rem xlatlist rem opusnode -f rem copy nodelist.sys \opus rem copy nodelist.idx \opus rem del nodelist.sys rem del nodelist.idx rem del nodelist.bbs rem del nodediff.* rem cd \opus goto start rem --- This group of operations may interest you. They are rem --- activated by exiting Opus with an ERRORLEVEL of 20. rem --- You will need to follow the directions in the RENUM rem --- documentation for setting it up. In this sample, rem --- RENUM resides on the A: disk drive. RENUM kills rem --- messages by a number of days, then renumbers the rem --- message areas in this sample. This is handy for rem --- keeping EchoMail areas down to a manageable size. rem --- To use this feature, change the two lines that start rem --- RENUM, referring to the RENUM docs, remembering to rem --- omit the "rem" from the beginning of the line. :renum rem a:\renum -s -d 30 2 -d 10 3 -d 10 6 -d 5 7 -d 2 8 -d 2 10 rem a:\renum -s -r 1 -r 2 -r 3 -r 4 -r 5 -r 6 -r 7 -r 8 -r 9 -r 10 goto start rem --- This is used with the O)utside command at the main rem --- menu. Refer to the OPUS.CTL sample main control file rem --- for more information. :outside watchcd com1 on ctty com1 goto end rem --- This set of operations is accessed when Opus exits with rem --- ERRORLEVEL 7. It simply runs the Opus matrix masher with rem --- the command line switches shown. The command line rem --- switches are explained more fully later, and in the rem --- OMMM documentation. :bundles cd\opus ommm -hc:\opus\outbound -mc:\msg\net -ic:\opus\bbs.prm -cc:\opus\ommm.ctl goto start :end "Tuning" a batch file can be a laborious project if you are trying to accomplish a variety of tasks with it. The sample included here will work with the resulting system. Not all of the functions shown above have been activated however. SCHED.BBS This file is a machine-readable representation of the schedules you have established for your system. You edit this file with the internal editor, or with a seperate utility such as OEVENT. SCHED.TXT This file is a text file representation of SCHED.BBS. The format of this file is the same as that shown on your screen while editing events with Opus' internal event editor. It is not included in this document for space considerations. SYSOPUS.COM This is one of many different types of USER.BBS editors for Opus. This program allows you to deleted users, change user information, add users, change user access levels, etc. Refer to the documentation included with SYSOPUS for more information on its use. You may also be interested in the program REMSYSOP. REMSYSOP performs the same functions, but can be used remotely via the Opus O)utside command. SYSTEM.BBS This is simply a control file for Opus. Some path information is kept inside this file in machine readable format. Do not modify the file, it is self-maintaining. SYSTEM??.BBS The files named with the word "SYSTEM" followed by one or two numbers are message and file area control files. The number in the name corresponds to the message/file area number. For example, information for both message area #3 and file area #3 would be kept in the file SYSTEM3.BBS. Do not modify these files. They are self-maintaining, and are edited only via the internal areas editor inside Opus. MK_USER.EXE You will only use this file once...to create the USER.BBS file, and to make the first entry in the file...YOU! Simply place the file in the designated directory, and run it. Follow the directions. Once your USER.BBS has been created, you can deleted this file. STRIP_Z.EXE Opus requires that the files named FILES.BBS (one for each file area) do NOT have a control-Z character at the end of the file. Most text editors place a control-Z at the end of a file as an end-of-file marker. If you manually edit a FILES.BBS file, run this file to eliminate the character from the end of the file. Simply type in STRIP_Z, followed by a fully qualified drive, path and filespec. ???PRIV.BBS ????PRIV.BBS These files make-up the menus encountered in various places within Opus. Although you can modify these files to a certain extent, it is not advised until you are an established Opus Sysop. These files also contain the priviledge levels associated with each command. The priviledge levels are changed using the internal Opus priviledge editor. The first three or four letters of the name (prior to the word PRIV) define what menu the file corresponds to. MAINPRIV.BBS, for example, corresponds to the main menu. OPUS.CTL This is the sample master control file distributed with Opus originally. We have included BBS.CTL (the same file, only not as complete) for use in your initial set-up. OPUS.CTL, however, lists the complete set of parameters available for your use in the master control file. We suggest examining this file to acquaint yourself with the various options. For the time being, use the included BBS.CTL file as the master control file instead. OPUS_CTL.EXE This is the master control file compiler. Simply type OPUS_CTL followed by the complete file name of your master control file (in this case, BBS.CTL), and press ENTER. In out example, the compiler would produce a file names BBS.PRM. This .PRM file is a machine readable control file that should not be directly modified. Do not delete your BBS.CTL after compilation. Retain it for editing at a later date. The name of the .PRM file is used as a command line parameter when running Opus (see the section on RUNOPUS.BAT). THE FILES IN C:\OPUS\MISC This directory contains all user-defined files for Opus. These include welcome screens, "bye-bye" screen, screens for new users, questionnaires, surveys, etc. The BBS.CTL file lists these files toward the end, on the lines with the word "Uses" at the beginning. Many Opus starter kits have samples of these files. NEWOPUS2.ARC also contains a complete set of these files ready for your use. These files can be edited using any common text editor capable of manipulating ASCII text files. Opus recognizes a varity of embedded control codes, listed in the Opus documentation, that perform various tasks including: inserting user information, creating questionnaires and surveys, using colors automatically for users that support color, etc. The package CTRLCNVT.ARC makes the use of such embedded commands much easier. Many of the included sample files contain embedded commands as well. These files make-up a significant portion of your system individuality and character. FILES IN C:\OPUS\HLP These are the various Opus help files. These files can be customized if needed, but they are usually pretty generic between Opus systems. FILES IN C:\OPUS\NODELIST This directory, as mentioned before, can be named or placed anywhere you care to. It contains the tools needed for processing the nodelist and nodediff files on a weekly basis. XLATLIST and Associated Files This is the nodelist handler for FidoNet. The master nodelist, titled NODELIST.??? (three numbers) is sent to you when you first establish a FidoNet compatible system and receive a node number. Weekly, a file named NODEDIFF.??? (three numbers) is sent to you. This file contains changes to the nodelist. XLATLIST processes these changes. The XLATLIST documentation explains more about XLATLIST. XLATLIST.CTL This is the current file for Net 104 used for nodelist processing with XLATLIST. It needs to be customized for your system prior to use. The file tells XLATLIST how to apply charges to the various numbers listed in the nodelist. OPUSNODE.EXE This file compiles the NODELIST.BBS file (generated by XLATLIST) into yet another nodelist...(actually two files), NODELIST.SYS and NODELIST.IDX. These two files need to be present in your C:\OPUS directory. Refer to the OPUSNODE documentation for more information. Your system will always have one NODELIST.??? (three numbers), one NODELIST.IDX and one NODELIST.SYS. NODELIST.BBS and out-dated nodelist and nodediff files can be deleted after use.